home *** CD-ROM | disk | FTP | other *** search
Text File | 1988-12-01 | 71.9 KB | 1,948 lines |
-
-
-
- J. Postel
- IEN 121 ISI
- 25 October 1979
-
-
-
- Internet Meeting Notes - 10, 11, 12 & 13 September 1979
-
-
-
-
- I. INTRODUCTION TO UCL - Jones
-
- Ron welcomed us to UCL and discussed the arrangements for facilities,
- refreshments, and lunch.
-
- II. OVERVIEW AND OBJECTIVES - Cerf
-
- Vint reviewed the need for a working internet system and cited the
- performance of the system as a key issue. The development of
- procedures to measure and test the performance of the internet are
- now important. Vint has pointed out that several conceptual design
- issues need to be resolved, for example, protocol support for voice
- conferencing in the internet.
-
- III. STATUS REPORTS
-
- A. DARPA - Cerf
-
- Vint reported that the Director of the ARPA Information Processing
- Techniques Office, Col. Dave Russell retired on 31 August. The
- new Director is Dr. Robert Kahn.
-
- The standardization of IP and TCP for use as the DOD networks
- protocol is progressing. Dr. Robert Lyons at DCEC is the
- Executive Agent. The only changes that are necessary are to
- incorporate mechanisms to pass the security and precedence
- information between the application program and TCP, and between
- TCP and IP. There already is an IP option to carry that
- information in the internet.
-
- There is a need for a way to test TCP implementations and
- applications that use TCP without taking a service machine down.
- For TOPS20s this will be satisfied by using BBNF. BBNF is
- currently only on the BBN RCCNET but will be connected to the
- ARPANET for October through December 1979.
-
- Vint acknowledged that there have been hardware delivery delays
- that have had a substantial impact on the internet program. The
- delivery schedules from manufactures are very long.
-
-
-
-
-
- Postel [Page 1]
-
- IEN 121
- Internet Meeting Notes
-
-
-
- The program managers in the ARPA office are coordinating to have
- all new applications use internet protocols.
-
- B. BBN - Haverty, Plummer, Strazisar, McNeill, Flood Page
-
- Jack reported that the BBN-Unix TCP is in regular use. Currently
- work is in progress to provide a user interface to the IP layer.
- The IP support is available as a subroutine package. The
- interface will be similar to the TOPS20 interface documented in
- IEN 108. BBN is also working on a VAX UNIX with the goal of
- having the current 11/70 UNIX and VAX UNIX be compatible at the
- applications level.
-
- Bill reported on the plan to attach BBNF to the ARPANET for ease
- in testing TCP and TCP using applications. In doing this testing
- it is preferred to have one person at a time to simplify the
- identification of problems. Note that one will have to use new
- 1822 (96-bit leaders) to access BBNF since it will be on IMP 67.
- The latest IP and TCP and Telnet are installed at ISID and ISIE
- TOPS20 Systems. In the last month or two several bugs have been
- identified and fixed. The next major step is to complete the
- TENEX version of TCP-4 and to eliminate any remaining instances of
- TCP-2.5. It is assumed that both the Packet Radio Project and UCL
- have completed their conversion to version 4, and that as soon as
- the SATNET project completes its conversion version 2.5 can be
- eliminated. The LDRSRV program was converted to use IP in a few
- hours. An FTP on TCP, based on ARPA FTP, is in debugging.
-
- Ginny reported that several gateways are running, most are MOS
- based. It is planned to phase out the remaining ELF based
- gateways.
-
- MOS Gateways
-
- at UCL between UCLNET and SATNET
- at NDRE between ARPANET and SATNET
- at BBN between ARPANET and SATNET
- at SRI between PRNET and ARPANET
-
- ELF Gateways
-
- at Ft. Bragg between PRNET and ARPANET
-
- It is planned to install a gateway at COMSAT between SATNET and
- the COMSAT local net. There is a new monitoring system. A
- configuration with a port expander and a gateway in the same
- machine is planned, it will be a tight fit.
-
- Dale reported on the SATNET conversion to use IP. There are still
-
-
-
- Postel [Page 2]
-
- IEN 121
- Internet Meeting Notes
-
-
-
- a number of programs to be converted, but it could be completed in
- about a month. Most of the remaining programs are used for
- maintenance or error recover. A weekend test was conducted using
- IP only. The major event impacting SATNET will be the removal of
- the NORWAY-LONDON ARPANET line at the end of September. This
- means all the LONDON ARPANET traffic will be routed via SATNET.
-
- David noted that the scheduled GMCC demonstration will be a
- presentation, since there is nothing to demonstrate.
-
- C. COMSAT - Mills
-
- Dave reported that the ETAM and GOONHILLY PSPs are in the field
- and the TANUM PSP will be shipped soon. There have been some
- minor problems, for example, the software checksum and the
- hardware checksum do not agree. It is expected that the PSPs will
- be on the air next month.
-
- Much of the COMSAT activity during the last few months has been
- directed to the NTC Demo in November and development of the Demo
- Terminal software. Currently, we have made arrangements for a
- suitable room and are now planning installation of lines,
- terminals and other gear. The demo will include speech, fax and
- the usual interactive and bulk transfers between ARPANET hosts and
- the Demo Terminal.
-
- The Demo Terminal software has been checked out at UCL using an
- LSI-11, floppy disk, LPCM and Port Expander connected to UCLNET
- (net 13). TCP/Telnet was tested with ISIE via UCLNET, SATNET and
- ARPANET. FTP was checked out in loopback mode via the UCL Gateway.
- The LPCM was operated in expensive dictaphone mode only, since
- support is not yet complete for SATNET streams. This software will
- play with the Demo Terminal software at COMSAT and at the NTC
- Demo.
-
- At COMSAT a Dacom 450 FAX machine has been delivered. This will be
- connected to the Demo Terminal and taken to the NTC site. Software
- to support this machine is now in frenzied development. When
- complete an update will be distributed to UCL. For local testing
- we are trying to arrange a direct connection to ARPANET (avoiding
- the SATNET for the time being) for debugging.
-
- D. DCA - Cain
-
- Ed reported that DCEC has a small (2-page) "C" program running in
- an 11/34 with two 1822 interfaces which implements a gateway.
-
-
-
-
-
-
- Postel [Page 3]
-
- IEN 121
- Internet Meeting Notes
-
-
-
- E. DOD - McFarland
-
- Ray noted that mid October is the target date for the draft DOD
- Standards IP/TCP document. These documents will be rewritten to
- military document conventions.
-
- F. ISI STATUS - Postel
-
- Jon noted that ISI is not implementing any IP, TCP or Gateways.
- ISI did attempt to write a program that used TCP on TOPS20. This
- program did not work (TOPs'20 crashed). Debugging is in progress
- with Bill Plummer and the ISI systems staff. ISI is working on an
- Internet Message Program. This is in an early testing phase and
- will be using TCP for inter module communication.
-
- G. LL - Forgie
-
- Jim noted that the main Lincoln effort has been on the ST protocol
- to be discussed later and described in IEN 119.
-
- Experiments with ARPANET-SATNET speech have been conducted with
- one source/destination in the ARPANET and another in the SATNET.
- There have been unexpectedly large delays in the SATNET streams,
- and in matching the ARPANET to the SATNET in the special purpose
- Gateway.
-
- H. MIT - Clark, Chiappa
-
- Dave discussed the status of the LSCNET. There is a 5 node system
- up and running. The development of a version 2 interface is in
- progress. There has been difficulty getting an LSCNET/ARPANET
- gateway working due to low level hardware problems. A Trivial
- File Transfer has been implemented directly on IP. In Multics the
- IP layer will act as a gateway. MIT will be involved in the
- XEROX Grant program. Dave will be involved in integrating the
- Xerox equipment into the LCS environment. A PDP-11 based gateway
- between LCSNET and the ETHERNET is contemplated.
-
- Noel commented that he saw a need for an effort to be made to
- convince groups to use IP rather than invent their own protocols.
-
- I. NDRE - Stensby
-
- NDRE has been assisting in the preparations for the speech demo.
- The protocol status is nearly the same as last reported. This is
- due to VDH connection problems. Much work has been done on
- debugging the connection. Possible bugs have been very difficult
- to track down because we lack control of vital parts of the
- system. A couple of bugs have been found and corrected in the
-
-
-
- Postel [Page 4]
-
- IEN 121
- Internet Meeting Notes
-
-
-
- NORD-10 VDH software without any substantial effect. The real
- problem seems to be that at certain times when the TIP has sent a
- packet out of sequence, it keeps retransmitting this packet
- instead of retransmitting the packet that is really missing.
-
- J. RSRE - Davies
-
- Brian reported that RSRE has programmed a gateway (based on
- IEN 30) and attempted to bring it up as a catenet gateway between
- UCLNET and RSRENET. RSRE will be bringing up a host with IP and
- TCP in about a month.
-
- K. SRI - Kunzelman, Mathis
-
- Ron reported that SRI is now operating two PRNETs in the San
- Francisco bay area, and one PRNET at Ft. Bragg, North Carolina.
- The net at Ft. Bragg is now eight terminals on two TIUs, and will
- grow to forty terminals.
-
- Jim reported that the LDRSRV at SRI-KA which now uses TCP-2.5 will
- be changed to use version 4 soon, tested at BBNF, and installed at
- ISID and ISIE. Jim is also working on a Port Expander and Mini
- Gateway combined.
-
- L. UCL - Kirstein, Jones, Treadwell, Cole, Bennett, Higginson
-
- Peter gave a brief overview of the UCL effort, then let various
- members of the UCL group give reports on their activities.
-
- Ron discussed the problems of including network software in a
- small Unix system. There was also some discussion of port
- expanders and X.25/IP interfaces.
-
- Steve reported on the situation with the FAX experiment. The main
- problems seem to be with the timing constraints of the device, and
- matching these to the flow control constraints of TCP. This
- system currently uses TCP-2.5 but will convert to version 4 soon.
-
- Bob reported on the development of a "C" to MOS linkage.
-
- Chris discussed the prototype NIFTP service that allows FTPs from
- EPSS to Tenex and vice versa. A Unix version of NIFTP has been
- implemented.
-
- Peter discussed the many flavors of X.25 one finds when building
- X.25/XXX interfaces.
-
-
-
-
-
-
- Postel [Page 5]
-
- IEN 121
- Internet Meeting Notes
-
-
-
- M. IRIA & CELAR - Zimmerman
-
- Hubert said that IRIA and CELAR would like to explore the
- possibility of cooperative research on the interconnection of
- networks. IRIA is working on local networks and interconnection
- with TRANSPAC and CYCLADES.
-
- N. UNIVERSITY OF ROCHESTER - Lantz
-
- Keith gave a brief overview of the environment at the University
- of Rochester and indicated the interest in becoming part of the
- internet system.
-
- IV. ACTION ITEMS
-
- A. DOCUMENTATION STATUS - Postel
-
- Jon reviewed the IENs issued since the last meeting.
-
- IEN Author Title
- --- ------ -----
-
- 108 Plummer Internet User Queues
-
- Describes the TOPS20 user interface to the IP.
-
- 109 Strazisar How to Build a Gateway
-
- Describes the messages Gateways exchange with each other and
- with hosts, i.e., the Gateway-Gateway protocol. The main
- focus is on the computation of connectivity and routing
- information. Replaces IEN 30.
-
- 110 Cerf Internet Addressing and Naming in a
- Tactical Environment
-
- Presents several addressing problems, particularly the
- "flying packet radio" problem.
-
- 111 Postel Internet Protocol
- 112 Postel Transmission Control Protocol
-
- The latest editions of the IP and TCP specifications. Not
- intended to be a change to the protocols but a better
- documentation of them. Replaces IENs 80 and 81.
-
-
-
-
-
-
-
- Postel [Page 6]
-
- IEN 121
- Internet Meeting Notes
-
-
-
- 114 Postel Protocol Options
-
- Summarizes the option available with IP and TCP. Replaces
- IEN 92.
-
- 115 Postel Address Mappings
-
- Shows how the addresses of various networks are carried in
- the Internet Address format. Replaces IEN 91.
-
- 116 Postel Internet Name Server
-
- Specifies the Internet Name Server, including same new
- features suggested by John Pickens. Replaces IEN 89.
-
- 117 Postel Assigned Numbers
-
- Lists the assigned number for various protocol fields, e.g.
- Networks, Sockets or Ports. Replaces IEN 93.
-
- 118 Postel Internet Protocol Handbook
- Table of Contents
-
- A one page list of the IENs that specify the current
- internet protocols. Replaces IEN 94.
-
- 119 Forgie ST - A Proposed Internet
- Stream Protocol
-
- The description of a Internet level protocol for voice
- conferencing. Includes features for establishing
- multi-addressee connections.
-
- The discussion that followed suggested several things that should
- be documented. For example, the higher level protocols (Telnet,
- FTP) should be in the internet protocol handbook, the procedure
- for determining parameters (e.g. retransmission timeout) should be
- documented, what to do in exception conditions should be
- described, testing procedures should be discussed (especially an
- acceptance test).
-
- Concern was expressed that the new editions of the IP and TCP
- specification were not suitably reviewed by the implementors. It
- was suggested that a version with changes marked would be useful
- (see Appendix B).
-
-
-
-
-
-
-
- Postel [Page 7]
-
- IEN 121
- Internet Meeting Notes
-
-
-
- B. EXPECTED DOCUMENTS
-
- 1. IP Generic Services - Do the two documents 1) the IP Spec by
- Jon (IEN 111), and 2) the Gateway Spec by Ginny (IEN 109),
- supply the information needed?
-
- 2. SATNET IP Services - Dale McNeill is working with Dave Mills
- (currently the only user). When the current experiments are
- completed a document will be produced.
-
- 3. Transition Plan - Vint will discuss the issues in a small
- group meeting and appoint a task force to prepare the plan.
-
- 4. Host IP Services - Bill Plummer will prepare a document based
- on his talk on How to Build a Host IP.
-
- C. XNET - It seems that XNET is not yet fixed to work with IP due to
- a technical disagreement between Jim Mathis and Ray Tomlinson.
- The solution to this is to be reported on at the next meeting.
-
- D. Hack IP at SRI-KA and LDRSRV - This is working according to Jim
- Mathis.
-
- V. INTERNET TRAFFIC EXPERIENCE - Davies
-
- RSRE has conducted some experiments sending messages looped back to
- themselves, with the loopback being located at various places, and
- using several input speeds and block sizes.
-
- At RSRE there is a multi-terminal TIU with some modifications to
- perform measurements. The TIU measures the time between the TCP
- segment first being sent and the acknowledgment arriving, a kind of
- round-trip time.
-
- The path is TIU via 2.4Kb line to PIXIE to PORT Expander to TIP into
- ARPANET. The input was either typing, a 1 octet segment traffic
- generator, or a 128 octet segment traffic generator. Histograms of
- performance under various inputs and loopback points were presented.
-
- The results indicate lower than expected performance and the
- speculation was that the limiting factor was the program interrupt
- 1822 interface (either in PIXIE or the Port Expander).
-
- It was noted that when two traffic generators were run sending
- segments to each other, ACKs were piggybacked 100% of the time both
- at the TCP level and at the X.25 level (recall the RSRE to PIXIE line
- operates the X.25 level 2 link protocol).
-
-
-
-
-
- Postel [Page 8]
-
- IEN 121
- Internet Meeting Notes
-
-
-
- VI. HOW TO BUILD A GATEWAY - Strazisar
-
- Ginny discussed the way gateways determine how to do routing. The
- actual messages used are documented in IEN 109.
-
- A gateway gathers information on network connectivity by polling its
- network interfaces and known neighbor gateways. The polling is done
- by sending a message, currently every 30 seconds. There is an
- algorithm to decide if a net or gateway is up or down based on the
- results of the polling. The routing algorithm is based on a distance
- measure, a directly connected network is zero distance, an
- unreachable network is infinite distance. The gateways exchange with
- neighbors their distance tables (substituting infinity in entries
- where the distance to the destination is greater than the distance
- from the neighbor). Routing information is sent only when something
- changes. A new gateway can join the system as long as old gateways
- can add a row to their tables dynamically.
-
- Note that "smart gateways" do all this routing and connectivity work,
- "dumb gateways" do not. Smart gateways try to route things to other
- smart gateways, but if that can't be done they may fall back to using
- compiled in fixed routes to dumb gateways.
-
- Danny Cohen suggested that there may be problems with this algorithm
- as the number of networks gets large.
-
- VII. HOW TO BUILD A HOST IP - Plummer
-
- Bill presented the general flow of processing in a Host IP. In
- general datagrams arrive from the connected network interfaces. Any
- fragmented datagrams are reassembled. Complete datagrams are entered
- into a queue. Datagrams addressed to other hosts may be forwarded if
- this host is acting as a gaweway, otherwise they are discarded.
- Datagrams addressed to this host are delivered to waiting protocol
- modules or user processes. User processes or protocol modules may
- create datagrams to be sent, these are queued and based on the
- destination address sent via one of the connected network interfaces.
-
- During the processing of arriving datagrams several checks must be
- made:
-
- 1. check the IP version number
- 2. verify the checksum
- 3. see that the length field and the amount received are
- consistent (amount received may be slightly greater due to
- padding)
- 4. check time to live
- 5. assemble fragments
-
-
-
-
- Postel [Page 9]
-
- IEN 121
- Internet Meeting Notes
-
-
-
- When sending a datagram the IP fills in several fields and makes a
- routing decision:
-
- 1. Insert source address
- 2. Insert any IP options called for
- 3. Insert time to live
- 4. Insert checksum
- 5. Make a routing decision, select an output interface, generate
- local net header and interpret type of service.
- 6. Queue for transmission
-
- The routing decision can be based on a table of network - gateway
- correspondences. For each network a gateway on a directly connected
- network is listed. If the host is notified to use a different
- gateway for that destination network the table can be updated. If a
- gateway breaks and the host can tell (e.g., receives a "destination
- dead" response) then switch to an alternate gateway. It is
- suggested that a heuristic for switching destination gateway is to do
- it when the higher level protocol (e.g., TCP) retransmits a segment.
- (However it is not clear the IP can tell a new transmission from a
- retransmission).
-
- In the area of congestion control Bill suggests that it is the rate
- that must be controlled which may be considered to determine an
- internet datagram interval. If a gateway tells a host to slow down,
- increase the internet datagram interval to, say, 130% of its former
- value. To avoid being stuck at a too large value for the internet
- datagram interval, reduce it to 95% of its former value every 30
- seconds or so.
-
- There is an issue of fairness in any congestion control. How can the
- IP properly allocate the available transmission capacity among the
- higher level protocol modules and users?
-
- The discussion suggested the need for a "Trace Datagram" that causes
- each gateway and the destination host to send back a note, a kind of
- "multi-echo."
-
- IP modules should provide a handle on the user side to explicitly
- cause a new routing to be calculated.
-
- The congestion control parameters may be very critical and sensitive.
- Dave Clark has done some simulation experiments and will prepare an
- IEN on this topic. There may be some interaction between
- source-destination host pairs in this area.
-
-
-
-
-
-
-
- Postel [Page 10]
-
- IEN 121
- Internet Meeting Notes
-
-
-
- VIII. STREAMS AND CONFERENCING - Forgie
-
- Jim presented the proposed ST protocol which is documented in IEN
- 119. The goals of ST are: (1) to provide a good base for
- point-to-point and conference packet speech, (2) to support research
- on effective traffic control techniques, (3) to support a
- demonstration of cost-effective speech, and (4) to operate as an
- extension of internet protocol.
-
- Jim indicated four requirements and corresponding approaches for
- meeting them: (1) guaranteed data rate - know requirement in advance
- and assign loads to links statistically, (2) controlled delay
- (predictable dispersion) - prevent congestion by controlling access
- on a call basis, (3) small quantity of speech per packet - use
- abbreviated header and aggregate small packets for efficiency, and
- (4) efficiency equal to or better than circuit switching without TASI
- (packet efficiency * link utilization > 45%) - abbreviated headers
- for packet efficiency and high link utilization with effective
- traffic control.
-
- One of the key decisions is to consider ST connections to be full
- duplex. The claim is made that this allows faster connection setup
- for conferences. There was some discussion on this point and the
- issue will be examined further.
-
- Another issue is the sharing of transmission capacity between speech
- (ST) and data (IP) in the internet.
-
- Also discussed was the identification of the route by a list of
- gateways rather than by a list of networks. The resources to be
- reserved are controlled by networks not gateways.
-
- One very interesting feature of ST is its mechanism for flexible
- multi-addressing and routing of messages such that each addressee
- receives at most one copy of a message.
-
- Jim presented the message formats and worked through an example of
- connection setup. There was some concern expressed about the effects
- of delayed duplicate control messages, and how ST operates under
- failure conditions. Also concern that several conference setups in
- competion may result is a deadlock similar to reassembly lock up.
-
-
-
-
-
-
-
-
-
-
-
- Postel [Page 11]
-
- IEN 121
- Internet Meeting Notes
-
-
-
- IX. SOURCE ROUTING & PROTOCOL MULTIPLEXING - Cohen
-
- Danny reviewed the proposed source routing procedure described in
- IEN 95. This mechanism provides a list of addresses for the datagram
- to pass through. Normal routing is used to move the datagram between
- these points. The route information for sending a datagram from A
- through B and C to D is expressed by A as TO: B, SR: C,D. At B this
- is changed to TO: C, SR: D, and at C it is changed to TO: D. The key
- is that the next address must be interpretable at the point it is
- used. This means that local (rather than internet) addresses may be
- used.
-
- The discussion focused around the issue of non internet addresses in
- the source route and how (if at all) to mark them. It seems
- desirable to let a source route contain any of the following in any
- order:
-
- 1. Internet Address.
- 2. Local Address (prefixed with an escape code and a length).
- 3. Network Address (Network part only).
- 4. Here - an address value that means this host, this net (or any
- host, or every host).
-
- Alternately one could have each address in the source route have a
- prefixed "op-code" that indicates what kind of address it is.
-
- Danny did not discuss the multiplexing of protocols (due to time
- pressures) but urged everyone to review IEN 90. It appeared that the
- multiplexing protocol was accepted (at least in principle).
-
- X. GATEWAY MONITORING & CONTROL CENTER - Flood Page
-
- David described the GMCC organization and the types of information
- that will be reported.
-
- The operation is much like the ARPANET NCC except that gateways are
- the objects of interest rather than IMPs.
-
- Gateways will communicate with a set of monitoring and control
- processes (running on a TOPS20 somewhere). These monitoring and
- control processes will update a central data base. The data in this
- data base may be accessed by Terminal Processes (i.e., User Interface
- Programs).
-
- A terminal process may take control of a gateway, but a gateway may
- only be controlled by one terminal process at a time.
-
- Three types of controls may be exercised: start or stop reports,
- inquiries, enable or disable traps. The reports give throughput
-
-
-
- Postel [Page 12]
-
- IEN 121
- Internet Meeting Notes
-
-
-
- statistics and interface up/down status. The inquiries give the
- gateway description (name, connectivity), echo response, or routing
- data. The traps give changes in the interface up/down status, or
- neighbor gateway up/down status.
-
- The information stored for each gateway in the central data base
- includes: the latest regular report, the interface address, the
- neighbor gateways, the reporting and trap status, the gateways own
- up/down status, and the process currently controlling the gateway (if
- any).
-
- In the future the GMCC will provide summary reports on traffic and
- up/down status.
-
- Other future topics are Performance Measures, Higher Level Fault
- Diagnosis, Accounting Information, and inclusion of information from
- NCCs.
-
- To use the GMCC facilities one would login to the GMCC host and run a
- terminal process. There was some discussion of the access control on
- people taking control of gateways. Also some concern about the
- artifact introduced into the measurement by accessing the GMCC via
- the gateway being measured, and also the effect on other gateways (or
- their statistics) of relaying the measurement messages to the GMCC
- host.
-
- David will prepare reports on: (1) GMCC Message Formats, (2) How to
- use a Terminal Process.
-
- XI. DISCUSSION OF SPEECH DEMO - Forgie
-
- Jim described the configuration for the speech demo. There are four
- sites involved: Lincoln Laboratory and ISI on the ARPANET and NDRE
- and UCL on the SATNET. There is a special purpose gateway at BBN.
- This gateway is a PDP 11/34 ELF system. The basic data rate for one
- site is 5 packets/sec, at this rate the gateway must handle 15
- packets/sec.
-
- In the ARPANET section of the conference the mode of operation is
- centralized control and distributed data. In the SATNET section the
- mode is distributed control and distributed data. The SATNET section
- uses a SATNET shared stream.
-
- XII. DISCUSSION OF FAX SYSTEM - Treadwell
-
- Steve described the configuration and operation of the FAX-Network
- system. The FAX machine is a DACOM 6000. It is connected to an
- LSI-11 (MOS operating system). The LSI-11 contains an interface to
-
-
-
-
- Postel [Page 13]
-
- IEN 121
- Internet Meeting Notes
-
-
-
- the DACOM, a TCP, and a controlling program. The controlling program
- interacts with a user at a display terminal.
-
- There is also a server FAX program on BBNC that accepts input and
- stores it in the file system, or on request sends stored FAX data
- from the file system.
-
- The operation is for the user to type on the controlling programs
- terminal a request to send FAX data to a file. A TCP connection is
- established between the LSI-11 and FAX server at BBNC.
-
- Pages are input through the DACOM and data is sent to BBNC and stored
- in the file. To move FAX data from the file to paper, the user
- enters a retrieve request on the controlling programs terminal.
-
- This system currently uses TCP-2.5. The next step will be to convert
- to using version 4. Also to change the address so the transmission
- will be through an internet gateway.
-
- There have been several problems in getting this working. Primarily
- the timing requirements of the DACOM and the flow control of TCP. A
- typical page results in 300,000 bits (with wide variance). The DACOM
- sends 585 bit blocks and if not accepted with in 6 seconds aborts the
- page. The total transmission path must support at least 100 bits/sec
- on the long term average.
-
- ISI is getting a RAPICOM 450 FAX machine and will use it in a similar
- way. (A RAPICOM 450 and a DACOM 6000 are identical machines). At
- ISI the FAX machine will be treated as a device (a peculiar terminal
- on TOPS20) rather than as a host.
-
- XIII. ADDRESSING ISSUES - Cerf
-
- Vint described several situations where a host may have several
- possible addresses and may wish to change between them dynamically
- without losing ongoing communications.
-
- A host may be dual (or multiply) homed, i.e., have two (or more)
- interfaces to the same net. A host may be connected to more than one
- net. Or a host may change nets.
-
- This last case is illustrated by a flying packet radio, passing over
- a series of ground PRNETs each connected to the internet via a
- gateway. The flying packet radio is for a time in the range of
- PRNET-1, then passes out of that range into the range of PRNET-2,
- etc.
-
- Another problem is partitioning. That is a network breaks into two
- (or more) parts which continue to function independently. Can a host
-
-
-
- Postel [Page 14]
-
- IEN 121
- Internet Meeting Notes
-
-
-
- in one part communicate with a host in another part via gateways and
- other networks?
-
- Does source routing solve the partitioning problem? Or is a scheme
- needed to dynamically assign unique addresses to each partition so
- that the ordinary gateway dynamic routing will solve the problem?
-
- Another proposal is to drop the requirement that connection be
- identified by the total address. By using only the pair of ports to
- identify a connection one could accept as a continuation of a
- conversation messages from a different host if it had the same pair
- of ports (and the expected sequence number).
-
- XIV. PARTITIONING - Plummer
-
- Bill discussed the problems of multiply connected hosts. If a host
- is connected to two networks, which are also interconnected via
- gateways, the host has alternate routes to use in sending messages.
- The internet gateways can exchange connectivity information. A
- multiply connected host cannot take full advantage of this without
- being a gateway itself and calling the host a network. Another
- problem is for a destination to answer a message from a multi-
- connected host. The multi-connected host would like to allow any of
- its interfaces to be used to receive the reply. To do this it could
- use a pseudo network number and act as if those interfaces were
- gateway connections.
-
- This use of network numbers for pseudo nets may use up the network
- numbers too quickly. Bill proposes what he calls host-group routing
- which uses a 32 bit address as if it were a network number. A host
- chooses one of its internet addresses as its "name". Gateways treat
- that name as a network name for connectivity and routing purposes. A
- mask can be used to allow groups of hosts to be routed based on one
- entry. Bill gave an example of how this might work and showed a
- routing table for a pseudo net at BBNC.
-
- This topic is to be discussed again at the next meeting.
-
- XV. RIG - Lantz
-
- Keith reported on the network environment at the University of
- Rochester. The key is a multi-machine multi-net system started in
- 1974. All communication between processes in this system is via
- messages. The system is based on Feldman's experience and other
- papers on message communication.
-
- The equipment involved includes: 4 Altos, 2 Eclipses, an Ethernet, 9
- terminals, 1 PDP-10, 1 VAX, and an ARPANET. The applications
- include: editing, compiling, file management. An important
-
-
-
- Postel [Page 15]
-
- IEN 121
- Internet Meeting Notes
-
-
-
- development is the virtual terminal model, which allows several
- processes to interact with a terminal using multiple possibly
- overlapping windows.
-
- The process level communication involves a name to address conversion
- by lookup in a name server, and an address to route conversion
- supported by a local kernel and network communication modules. Three
- communication styles are supported: atomic transactions, connections
- or streams, and asynchronous messages.
-
- One problem area is protocols. There are too many: U of R Ethernet,
- PARC Ethernet, ARPANET, DECNET, internet. Can all these live in
- harmony?
-
- XVI. SUMMARY OF SMALL GROUP MEETINGS
-
- 1. PERFORMANCE MEASUREMENT SMALL GROUP MEETING - Kunzelman
-
- This group discussed the need for performance measurements of the
- internet protocols at all levels. The group reviewed the current
- work, discussed performance metrics, measurement tools, and
- documentation of measurement methods and results.
-
- The group recommends that specifications of performance measures
- for IP and TCP be written, that a set of tests for IP, TCP, and
- higher level protocols be defined, and that a bibliography on
- performance measurement be prepared.
-
- Please see Appendix C for further detail on this group meeting.
-
- 2. UNIX SMALL GROUP MEETING - Cain
-
- Three topics were addressed in the UNIX small group meeting:
-
- 1. Use of network UNIX on small PDP-11's
- (specifically, the 11/34 and the 11/40).
- 2. MOS work on UNIX systems.
- 3. Use of UNIX on VAX machines.
-
- For PDP-11's which do not support the separation of instruction
- and data space, incorporating the widely distributed NCP programs
- into the UNIX kernel usually produces an object which is barely
- small enough to boot, even after greatly reducing various system
- parameters. Processes like TCP and Telnet have to share the scarce
- remaining space, and are bound to perform poorly because of
- swapping. Noel Chiappa is about to obtain, from NOSC, a version of
- UNIX which has no disk buffers in the kernel data space, and will
- attempt to install the NCP kernel software. Performance of this
-
-
-
-
- Postel [Page 16]
-
- IEN 121
- Internet Meeting Notes
-
-
-
- version of UNIX is uncertain, but a mailing list (see Appendix A)
- has been established for those interested in the outcome.
-
- UCL, MIT, and BBN are all interested in doing MOS work in a UNIX
- environment. The problem is that there is a variety of file types
- (a.out, .obj, .rel, .lda) which must somehow be combined into an
- object which is loadable into an LSI-11, and is understandable by
- DDT or a similar debugger. UCL has "C" interfaces to MOS system
- calls and some utilities which Noel Chiappa will attempt to put in
- a "nice" UNIX environment, and make them available for others. A
- mailing list (see Appendix A) was established for those who wish
- to follow his progress.
-
- Keith Lantz discussed a meeting with ARPA, Rochester, CMU, and
- others associated with ARPA-funded research involving VAX
- machines. At the meeting, the decision was made to use UNIX on the
- VAX machines, specifically the version of UNIX modified at
- Berkeley to take advantage of the VAX paging hardware. The source
- of support for the VAX UNIX is not yet named. Rochester and CMU
- are both interested in implementing TCP and IP on their VAX
- machines. A mailing list (see Appendix A) was established for
- those interested.
-
- 3. TCP VERSION 4 AND TIU SMALL GROUP MEETING - Haverty
-
- The small group meeting on the status of the new TCP
- implementation and TIU also covered some general issues of TCP
- support for MOS-based systems in general.
-
- Jim Mathis reported that recent work on the MOS TCP version 4
- implementation involved separating the code into individual
- modules, to isolate the network- and operating-system-dependent
- sections of the code. The major part of the TCP code is now in the
- TV4PRO module. Operating system support code exists in TV4MOS or
- TV4ELF, depending on the operating system involved. The
- "released" versions of this implementation are available on the
- SRI-KL machine in the MOS-DEVEL directory, but they will be moved
- soon to PKT-LSI-11.
-
- Ongoing work with the TCP involves addition of an internet layer
- which will be accessible to user processes using entry points to
- be defined. This will occur in a later release of the software,
- which is not expected to involve any changes to the TCP interface
- to user processes. The internet layer will also implement some of
- the gateway-gateway protocol functions.
-
- In addition, the software can be extended to support multiple
- hardware interfaces, to permit multi-homing of hosts on multiple
- networks. This work however is not yet in progress.
-
-
-
- Postel [Page 17]
-
- IEN 121
- Internet Meeting Notes
-
-
-
- The discussions which followed identified a need for two new
- mechanisms within the user community. The first is simply an
- announcement mechanism, to inform users of the SRI software of new
- releases, the changes which have been made, functions added, and
- location of the code itself. A second mechanism involves
- integration of changes developed at user sites into the
- SRI-maintained sources. For example, software to support other
- network types must be done at the site running the network, but
- should then be integrated into the standard sources.
-
- Because of the need for sites other than SRI to implement
- network-interface software, the internal interface between the TCP
- and internet layer and the local-net module must be clearly
- defined and stabilized. MIT is likely to be the first site to
- implement a new local-net module.
-
- Further discussion explored details of the functionality of the
- existing TCP implementation, and requirements which various user
- projects expect to have in the future. Some of the facilities
- not yet implemented include:
-
- o ability to have multiple connections in one MOS process
- o reassembly of internet fragments
- o full processing of EOL
- o processing of "rubber EOL"
- o user access to URGENT functions
- o full functionality at the Telnet user interface
-
- The last area explored identified the need for additional work on
- the Telnet implementation, to, for example, provide the ability to
- send remote RESETs.
-
- A short discussion of "coming attractions" followed, including the
- following expected changes:
-
- o internet layer in Bliss, probably by the end of 1979
- o use of the internet name server by Telnet
- o XNET server within MOS, to debug MOS processes remotely
-
- The TCP software is currently written in MACRO-11. It is a
- candidate for conversion to Bliss, but this will not be done until
- the Port-expander software is converted.
-
- One possible performance limitation was identified during the
- discussion. Currently, data is ACKed when it is accepted by a
- user process. Since this can be significantly later than the
- actual receipt of the data from the network, throughput might be
- improved by modifying the TCP to ACK data on receipt from the
- network.
-
-
-
- Postel [Page 18]
-
- IEN 121
- Internet Meeting Notes
-
-
-
- A short discussion of TIU issues identified the need for
- determining how many terminals can be supported by a TIU at once,
- in two cases. In a heavy-use situation, the limitation on number
- of active, high-throughput terminals should be determined. This
- number is probably limited by the raw speed of the LSI-11, and may
- be increased by conversion to faster hardware such as the
- PDP-11/23 when it is available. A second case involves the
- limitation on support of low-usage terminals. This limit involves
- primarily how many serial interfaces can be connected to the
- LSI-11 and configured in the packaging.
-
- The meeting also demonstrated a need for better interchange of
- information among the participants and general community of users
- of MOS, TIUs, and related hardware and software. A mailing list
- is being set up, called MOS-TCP, for this kind of activity (see
- Appendix A).
-
- 4. LONDON-NORSAR LINE AND SATNET SMALL GROUP MEETING - McNeill
-
- Dale said that loading of the Goonhilly SIMP and the london TIP
- over the satellite channel is operational. Monitoring and control
- paths exist for all SIMPs; sufficient backup paths exist through
- use of the satellite channel and gateways connected to other
- SIMPs.
-
- Vint announced that beginning January 1, l980, the NORSAR-SDAC
- circuit will become a military circuit for operational data only.
- Seismic data traffic from the NORSAR TIP will continue to be sent
- on this line.
-
- Funding for the London-NORSAR circuit ceases October 1, 1979.
- Peter anticipates that the ARPANET direct connection circuit via
- SATNET (line 77 between London and SDAC) will be needed to provide
- ARPANET connectivity to the London TIP until some time after
- October l980. This circuit will continue to provide ARPANET
- service to the Rutherford Lab, EPSS, and the London TIP. The
- long-term goal is to have internet service to London only using
- the UCL gateway attached to SATNET. Prerequisite is a change of
- the London TIP to a host (TCP TIP). The mechanism of internet
- loading and support of London machines must be developed.
-
- In conflict with the maintenance of operational service to London
- is the introduction and checkout of PSP Terminals, the checkout
- and release of new SIMP software, and the checkout and performance
- of the NTC demonstration. Hardware and software development will
- be restricted to after 1400 EDT, while operational service will be
- maintained from 0200 to 1400 EDT, daily.
-
-
-
-
-
- Postel [Page 19]
-
- IEN 121
- Internet Meeting Notes
-
-
-
- 5. NTC DEMO PLANNING SMALL GROUP MEETING - Mills
-
- The principal results from that meeting were a revised plan for
- network connectivity and a change in the way speech would be
- handled. Specifically, it was decided that Jim Forgie's software
- would be used in the BBN and UCL gateways with the LPCM operated
- from Washington via appropriate data lines to the BBN Gateway. Jim
- has already made provision for this in the LPCM design, but it has
- not been operated in this mode before.
-
- Datagram traffic for the Demo is planned to be sent via
- Clarksburg, with a backup to Etam via a backdoor connection via
- the Clarksburg SIMP internal gateway and the RCC or other suitable
- hack. UCL will participate in the Demo from London with live
- speech and fax. Participation by NDRE will depend on a PSP
- Terminal being installed there.
-
- Jim mentioned a couple of minor problems with the LPCM hardware.
- Correcting these will probably involve sending ROMs to the various
- sites. There is a question of Gateway reliability which leaves all
- of us nervous
-
- 6. IP/TCP FLOW CONTROL SMALL GROUP MEETING - Clark
-
- This meeting was a fairly informal discussion among the
- implementors of TCP and gateways. Several topics were discussed.
- 1) How to manage RFNMs on internet link.
- 2) A simple simulation of a host responding to quench messages.
- 3) How to perform quenching experiments, given the current level
- of internet operation.
- 4) Should the TCP-IP or application-TCP interface be
- specified/standardized with respect to flow control?
-
- While the discussion was fruitful, no substantial conclusions were
- drawn.
-
- 7. X.25 GATEWAY SMALL GROUP MEETING - Binder
-
- The purpose of this meeting was to review various factors
- impacting the development of an ARPANET/X.25 gateway using an
- LSI-11 to provide a 50 Kbps full duplex service. The meeting
- basically covered only the issue of hardware interfacing to the
- X.25 network. Three different interfaces were discussed: a
- byte-interrupt device, a non-DMA packet-interrupt device, and a
- full DMA device.
-
- The byte-interrupt interface and related level 2 and 3 X.25
- software has been developed by UCL and is now available for use.
- Although precise throughput measurements have not yet been made,
-
-
-
- Postel [Page 20]
-
- IEN 121
- Internet Meeting Notes
-
-
-
- experience with the LSI-11/MOS system by meeting attendees
- indicated that a byte-interrupt configuration would not achieve 50
- Kbps full duplex operation. In particular, measurements by SRI
- have indicated a maximum of about 50 Kbps through a looped-back
- 1822 byte-interrupt interface on a MOS system running only a
- message generator (no gateway or second network interface).
-
- The packet-interrupt interface is being developed by RSRE, and
- along with level 2 software is expected to be checked out in 6-8
- weeks. This interface contains 4K bytes of buffering, shared among
- input and output. Operation consists of copying packets between
- the interface memory and main memory, with a single interrupt
- associated with each packet.
-
- UCL plans to develop a full DMA interface, but this is not
- expected to be available until anywhere from 8 to 12 months from
- now.
-
- A framing issue presently exists in that both IPSS and Telenet
- X.25 networks now use bi-sync framing. However, both are expected
- to make HDLC bit-oriented framing available this fall.
-
- 8. PORT EXPANDER SMALL GROUP MEETING NOTES - Davies
-
- 1. Hardware Delivery Outlook.
-
- SRI has fifteen systems on its order book and enough components
- to build only two complete ones at this time. Some of the
- hardware bottlenecks are:
- a) Boxes from DEC - deliveries up to January '80.
- b) Low power Schottky chips for 1822 DMA boards.
- c) Cable connectors for 1822 units - Amphenol.
- d) Control Panels.
-
- Delivery of port expander units would continue at a slow rate
- at least until the end of the year with Vint Cerf nominating
- the recipient of each system as it rolls off the production
- line.
-
- A postscript on the hardware discussion concerned the
- robustness card which may have to be reprogrammed for automatic
- loading from nets which are not on the ARPANET. The robustness
- card uses UV erasable PROMS. Mathis said that there would be
- documentation supplied with the robustness card indicating how
- this should be done. The cards themselves were just coming back
- from the printed circuit facility and although one or two types
- of chip for this board were in short supply, it was hoped that
- board delivery would begin at the end of September.
-
-
-
-
- Postel [Page 21]
-
- IEN 121
- Internet Meeting Notes
-
-
-
- 2. Software Developments.
-
- Most of the discussion centered around the new facilities which
- would be offered with the SRI supported BLISS-11 version of the
- PORT Expander code. Some of these features are:
- a) Provision of NOP handling.
- b) Provision of IMP padding.
- c) Flow control facility.
- d) Facility to simulate RFNMs internally.
-
- There were still some open ended problems like what should a
- port expander do when the NCP host crashes. One possible
- approach is to offer two different solutions to this problem
- and select one at configuration time.
- Possible release dates for the BLISS-11 version of the port
- expander were mid October if Mathis can get an IMP port for
- debugging or up to a month after depending on the priority of
- the work.
-
- Finally Strazisar joined the meeting for a discussion on
- integrating the mini-gateway code and port expander code into
- the same machine. Clark suggested that this integration problem
- would become almost trivial if someone wrote a null 1822 driver
- under MOS which allowed buffers to be passed across the driver
- without copying. Strazisar volunteered to take a debugged copy
- of Mathis' port expander code and integrate it into the
- mini-gateway with an optimistic delivery date of the End of
- November.
-
- 9. TCP IMPLEMENTATION SMALL GROUP MEETING - Cerf
-
- The discussion focused on the changes to IP required by DCA to
- satisfy the DOD security and precedence needs. The existing IP
- option for S/P/T does most of what's needed, but in addition the
- TOS field will be redefined slightly to be:
-
- 0 1 2 3 4 5 6 7
- +-+-+-+-+-+-+-+-+
- | |S| |S|S|
- | PRC |/|Rel|/|P|
- | |D| |R|D|
- +-+-+-+-+-+-+-+-+
-
- That is:
-
- Bits 0-2: Precedence
- Bit 3: Stream or Datagram
- Bits 4-5: Reliability
- Bit 6: Speed or Reliability
-
-
-
- Postel [Page 22]
-
- IEN 121
- Internet Meeting Notes
-
-
-
- Bit 7: Speed
-
- This information has to be passed up and down the layers of
- protocol. Enforcement of the security and precedence is up to
- each host. There needs to be a specification of how to interpret
- and implement these functions. Preemption rules must be specified
- too, for the higher level protocols.
-
- There was some discussion of the unauthorized use of security and
- precedence features. The basic rule is to act on it speedily now
- and to log the header of the message so one can ask later if the
- originator was authorized.
-
- 10. TCP APPLICATIONS SMALL GROUP MEETING - Postel
-
- This group discussed problems in programming application programs
- that use TCP. Postel had a problem figuring out how to use the
- user/TCP interface (JSYSs) to create a successful TCP using
- program. The problem may be with the documentation. Haverty has
- the problem that programs don't work but don't crash either.
- Clark said his TCP can't tell the user anything more specific than
- "it didn't work."
-
- What is needed is better documentation, fault isolation tools, and
- user level debugging aids. Also a memo on what is available,
- e.g., a traffic generator at BBN-UNIX.
-
- 11. ST PROTOCOL SMALL GROUP MEETING - Hoversten
-
- This group first made up a detailed agenda of issues to discuss.
- In general the topics included:
-
- Connectivity
- Routing
- Stability
- Protocol Layering
- Resource Allocation
- Information Exchange
-
- Further discussion of the role of ST in resource allocation is
- needed. It is agreed that ST provides a structure to support
- multi-addressing and a resource allocation policy.
-
- The relationship of ST to IP is that ST is experimental, will be
- implemented at a small number of sites, and will have IP imbedded
- in it.
-
-
-
-
-
-
- Postel [Page 23]
-
- IEN 121
- Internet Meeting Notes
-
-
-
- 12. 1822 BOARD PROBLEM SMALL GROUP MEETING - Mathis
-
- The problem with 1822 boards is being worked on at SRI. Software
- for the TIU which circumvents the problem will be made available.
- A hardware fix is being studied.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Postel [Page 24]
-
- IEN 121
- Internet Meeting Notes
-
-
-
- XVII. AGENDA FOR NEXT TIME
-
- The next meeting is February 4-6 at SRI International in Menlo Park.
- Ron Kunzelman is the contact.
-
- Agenda Items:
-
- 1. Kirstein, Davies, Frankel - Internet Performance Experience
-
- 2. Flood Page - Longterm Gateway Statistics
-
- 3. Cerf - Schedule & Milestones Review
-
- 4. Forgie - ST Protocol
-
- 5. Cohen - ST Performance
-
- 6. McQuillan - Internet Routing
-
- 7. Cain, McFarland, Cerf - IP/TCP Acceptance Testing
-
- 8. Plummer, Tomlinson - Higher Level Protocols FTP & Integration
- with TCP
-
- 9. Postel - Internet Message Handling Interim FTP Based Multi
- Media Supporting
-
- 10. Deutsch - BBN - FAX & Text Message System
-
- 11. Cerf - Multi Homing & Partitioning
-
- 12. Plummer - Host Group Routing
-
- 13. Demos:
-
- A. GMCC Monitoring - Flood Page
-
- B. Fault Isolation in TIU - Mathis
-
- C. Internet Message Transport - Postel
-
- Action Items:
-
- 1. Milestones - each contractor is to provide a list of
- milestones to Cerf. The intention is to quantize tasks and
- identify increments in capability. The goal is to make
- progress easily detectable. The combined milestones will be
- distributed to the internet group, and will be reviewed at the
- next meeting.
-
-
-
- Postel [Page 25]
-
- IEN 121
- Internet Meeting Notes
-
-
-
- 2. Monthly Reports - each contractor is to provide a monthly
- report to Postel. The report should note accomplishments,
- progress on milestones, unusual events, problems. A summary
- of all reports will be distributed to the internet group.
-
- 3. XNET - to be converted to version 4 by Jim Mathis and Ray
- Tomlinson.
-
- 4. Host IP Document - Bill Plummer is to write an IEN on how to
- build a host IP.
-
- 5. GMCC - David Flood Page will write an IEN on GMCC message
- formats and an IEN on how to use a terminal process .
-
- 6. Congestion Control - Dave Clark will write an IEN on
- simulation experiments in IP congestion control.
-
- Future Meetings Schedule
-
- 1980
- FEB - SRI
- MAY - MIT
- SEP - RSRE
- 1981
- JAN - ISI
- MAY - ARPA
- SEP -UCL
-
- XVIII. DOCUMENTS DISTRIBUTED
-
- IEN Author Title
- --- ------ -----
- 109 Strazisar How to Build a Gateway
- 110 Cerf Internet Addressing and Naming in a Tactical
- Environment
- 119 Forgie ST - A Proposed Internet Stream Protocol
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Postel [Page 26]
-
- IEN 121
- Internet Meeting Notes
-
-
-
- XIX. ATTENDEES
-
- Vint Cerf ARPA Cerf@ISIA
- Robert E. Kahn ARPA KAHN@ISIA
- Dick Binder BBN BINDER@BBNE
- Jack Haverty BBN JHAVERTY@BBND
- Dale McNeill BBN DMCNEILL@BBNE
- David Flood Page BBN DFLOODPAGE@BBNE
- William Plummer BBN Plummer@BBNA
- Virginia Strazisar BBN STRAZISAR@BBNA
- Hoi Y. Chong COMSAT Mills@ISIE
- David Mills COMSAT Mills@ISIE
- Chip Bumgardner CTEC CHIPS@BBNC
- Jack Hammett DARPA-IPT Hammett@ISIA
- Ed Cain DCA Cain@EDN-UNIX
- Ray McFarland DoD McFARLAND@ISIA
- Michel L. Audren French Ministry Observer
- Dominique A. Truchetet of Defense Observer
- Hubert Zimmerman IRIA HZim@BBNC
- Danny Cohen ISI Cohen@ISIB
- Jon Postel ISI Postel@ISIB
- Estil Hoversten Linkabit Hoversten@ISIA
- Noel Chiappa MIT JNC@MIT-AI
- Dave Clark MIT Clark@MIT-MULTICS
- Jim Forgie Lincoln Lab FORGIE@BBN
- Frank Deckelman NAVELEX DECKELMAN@ISIA
- Aage Stensby NDRE AAGE@SRI-KA
- Andrew Bates RSRE RSRE-T4@ISIA
- Brian Davies RSRE RSRE-T4@ISIA
- Allan J. Fox RSRE RSRE-T4@ISIA
- John Laws RSRE RSRE-T4@ISIA
- Ron Kunzelman SRI KUNZELMAN@SRI-KL
- Jim Mathis SRI Mathis@SRI-KL
- Robert Cole UCL UKSAT@ISIE
- Sunil K. Das UCL PKT-UCL@SRI-KL
- Peter L. Higginson UCL UKSAT@ISIE
- Andrew Hinchley UCL UKSAT@ISIE
- Ron Jones UCL UKSAT@ISIE
- Peter Kirstein UCL Kirstein@ISIA
- Alan J. Mayne UCL UKSAT@ISIE
- Steve Treadwell UCL UKSAT@ISIE
- David Lloyd UCL/UKMOD LLOYD@ISIA
- Keith A. Lantz U of R LANTZ@SRI-KL
-
-
-
-
-
-
-
-
-
- Postel [Page 27]
-
- IEN 121
- Internet Meeting Notes
-
-
-
- APPENDIX A
-
- The following special interest group mailing lists have been set up
- by Noel Chiappa at MIT-ML. To use them, send to <group>-PEOPLE at
- MIT-ML [or just <group> (DON'T include the "<"'s)].
-
- If you want to be on one or more of these mailing lists please send a
- note to Noel, JNC@MIT-AI (not to the whole group).
-
- If you get a message from Person and to a mailing list, DO NOT send
- your reply to the mailing list AND Person; the MIT-ML mailer isn't
- smart enough to notice and will send duplicate copies to Person.
-
- MOS-UNIX MOS support on UNIX
-
- SMALL-UNIX UNIX on small machines
-
- VAX-UNIX UNIX on VAX
-
- MOS-TCP MOS, TIU and the MACRO-11 TCP
-
- MOS-PE Port expander / Minigateway
-
- NET-UNIX Network support on any UNIX
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Postel [Page 28]
-
- IEN 121
- Internet Meeting Notes
-
-
-
- APPENDIX B
-
- IP and TCP Specification Differences
-
- The following is a brief description of the difference between IEN-80
- and IEN-111 (IP), and between IEN-81 and IEN-112 (TCP).
-
- In both cases the new documents are intended to simply be better
- documents, and no significant changes to the protocols are intended.
- There are many minor changes of wording, punctuation, or spacing, so
- that a source compare would catch many many paragraphs in which there
- is no significant change. It is intended that the text added (or in
- some cases deleted) lead to an easier to understand description of
- the protocols.
-
- IP Differences
-
- 1. A much more specific description of a fragmentation and
- reassembly procedure is included.
-
- 2. Some Options are changed or added:
-
- a. Three options are added for use by the BCR protocol.
-
- b. A Stream-ID option is added.
-
- c. The Source Route option is changed to conform with IEN-95.
-
- d. The Return Route option is added to conform with IEN-95.
-
- e. The Error Report option is expanded to have several specific
- error codes., and a standardized IP header for error reporting.
-
- TCP Differences
-
- 1. Two additional States are introduced in the connection closing
- sequence.
-
- 2. The EOL sequence number fixup procedure is changed to be based
- on remembering the sequence number of the beginning of the most
- recent buffer rather that the initial sequence number of the
- connection.
-
- 3. In many cases the RST is not required to acknowledge that
- segment that caused the reset to be generated, and in many cases
- it is not necessary to check the ACK value to verify a RST.
-
-
-
-
-
-
- Postel [Page 29]
-
- IEN 121
- Internet Meeting Notes
-
-
-
- APPENDIX C
-
- Minutes of Internet Subgroup Meeting for Performance Measurement
-
- Present: Ron Kunzelman (SRI) (Chairman), Noel Chiappa (MIT),
- Brian Davies (RSRE), Stephen Edge (UCL), David Flood Page (BBN),
- Andrew Hinchley (UCL), Ron Jones (UCL), Bob Kahn (ARPA), Peter
- Kirstein (UCL), Alan Mayne (UCL) (Minute-taker), Ray McFarland
- (DOD)
-
- Kunzelman pointed out that there is need for performance
- measurement at different levels of protocol, including
- measurements on Telnet and FTP at the user level, TCP at the
- transport level, and datagrams at the internet level. The meeting
- then considered various specific aspects of measurement.
-
- Measurement Work Now Being Done or Being Planned
-
- BBN (Flood Page) will do some performance measurements at the
- datagram level on traffic passing through gateways; no tests are
- envisaged. The BBN gateway will monitor IP traffic going through
- the gateway. BBN is looking at CPU utilization, and can also
- extract interface information by address pairs. BBN (Wingfield)
- is doing some performance tests on TCP. Throughput and delays
- have been investigated.
-
- SRI is measuring Telnet throughput (bits/sec) from TOPS20 and
- TENEX hosts.
-
- UCL is trying to time FAX transmissions, and NIFTP transmissions
- at the user level. UCL would like to measure individual
- performances end-to-end, to see if there is any destructive
- interference. For ARPANET-SATNET-ARPANET transmissions, there is
- a need to know the best ARPANET performance, the best gateway
- performance, and the best Satnet performance, and then compare the
- combination of these with the best actual ARPANET-SATNET-ARPANET
- performance, to see whether they are comparable or differ by an
- order of magnitude.
-
- RSRE (Davies) has previously measured with old PIXIE, and would
- now like to repeat some of these measurements with new PIXIE.
- Measures have been made of round-trip TCP ack times. The
- measurement techniques consist mainly of turning the traffic
- generator on for about five minutes at a time, then obtaining a
- delay histogram.
-
-
-
-
-
-
-
- Postel [Page 30]
-
- IEN 121
- Internet Meeting Notes
-
-
-
- Performance Metrics
-
- The following metrics have been used to measure ARPANET
- performance:
-
- 1. ARPANET has problems of low bandwidth, hence uses
- throughput metrics such as packets/sec and user-bits/sec.
-
- 2. SATNET has long delays, hence measures mean transmission
- time.
-
- 3. PRNET is liable to high loss, hence measures the percentage
- of missing packets.
-
- 4. Packet efficiency is the ratio of information packets
- received to total packets received (the difference being
- due to control and retransmission overhead).
-
- Kirstein stressed the need for better individual metrics, and then
- for developing algorithms for combining them. For example, both
- bits/sec and packets/sec are important.
-
- He also raised the question of how the performance varies when
- going through different combinations of networks.
-
- Measurement Tools
-
- Tools currently being used in Arpanet include:
-
- 1. At the user level, FTP + "stopwatch" for bandwidth and
- Telnet + "stopwatch" for measurements of remote echo time and
- bandwidth.
-
- 2. Timestamps in pickup packets.
-
- 3. Echo server in gateways.
-
- 4. Traffic generators and sinks.
-
- There is also a possibility of using synchronized clocks to
- measure one-way times and asymmetric delays as well as round
- trip times. Hinchley is looking at interval times between
- successive packet streams, as a method of measuring delays.
-
- Measurement Needs
-
- Kunzelman pointed out that there is currently no measurement at
- the transport level in the ARPANET. Statistics are needed for the
- distribution of user traffic, which can be measured on entry to
-
-
-
- Postel [Page 31]
-
- IEN 121
- Internet Meeting Notes
-
-
-
- the internet system. There is also a need to have statistics for
- the distribution of packet sizes.
-
- More measurement is needed of round-trip TCP ack times: so far,
- this has been done only by RSRE. Also in TCP, measurements are
- needed of retransmissions and checksum errors. TCP-specific
- measures should be separated from general network and gateway
- measures, although such separation might be difficult to achieve
- in practice.
-
- Mayne would be grateful to anyone who would send him empirical
- data that would be useful to help validate his proposed simulation
- and theoretical studies, especially on problems of joint
- ARPANET-SATNET operation. It was pointed out that McQuillan has a
- large amount of empirical data.
-
- Some Problem Areas
-
- Kahn pointed out the need to isolate problem areas, such as
- optimization and tuning, for which measurements are needed. Some
- of these problems relate to research and development about
- networks, including obtaining insights about their behavior,
- others are concerned with the operational control of networks, and
- there is also the problem of persuading some network users that
- they actually have problems!
-
- Kirstein said that a big problem is to put uniform methods of
- measurement into the internet environment; this is very difficult
- and requires much thought.
-
- Kahn asked if we could do absolute performance measurements, or
- whether they are all relative.
-
- Kahn said that measurements could contribute to the understanding
- of various problem areas, for example: performance tuning and
- other parameter optimization, retransmission strategies,
- alternative routing strategies, minimum delays for
- interactive-type traffic, cost considerations, robustness and
- recoverability.
-
- Mayne mentioned two important incentives for carrying out
- comprehensive measurements:
-
- 1. Validation of simulation runs and theoretical models.
-
- 2. Obtaining insights into what is happening, especially in
- network operating problems of crucial practical importance.
-
-
-
-
-
- Postel [Page 32]
-
- IEN 121
- Internet Meeting Notes
-
-
-
- Documentation
-
- Mayne said that is would be valuable to prepare a comprehensive
- list of all documents relevant to network measurement, including
- papers on methods and tools, measurement software and write-ups of
- that software, and collections and summaries of actual performance
- data. He suggested that each organization participating in the
- internet, should contribute relevant entries, and he himself will
- prepare an annotated bibliography of relevant UCL literature. He
- is also willing to act as a mailbox for collecting information
- from the other organizations.
-
- It was pointed out that important documents in this area have been
- written by Kleinrock, McQuillan, and Wingfield, and also at UCL.
-
- Recommendations for Further Action
-
- 1. Study network performance in relation to types of network
- subsystem, including network as a whole, gateways, hosts,
- operating systems.
-
- 2. Write specifications of performance measures for TCP (it
- was suggested that this might be done by Wingfield), user
- level protocols, and IP.
-
- 3. Define a set of tests for IP, Datagram, TCP, higher level
- protocols, etc.
-
- 4. More work needs to be done on IP, for example, using GGP
- and echo packets and measuring round trip times, also
- investigating loss rates including numbers of duplicate packets
- and packets out of order.
-
- 5. Prepare and adequate bibliography of documents on
- performance measurements, and keep it up to date.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
- Postel [Page 33]
-